home *** CD-ROM | disk | FTP | other *** search
/ PC World 2000 February / PCWorld_2000-02_cd.bin / Software / Servis / FFE / MOD.SWG / 0057_PTM PolyTracker MOD.pas < prev    next >
Pascal/Delphi Source File  |  1997-05-11  |  23KB  |  571 lines
  1. 1) Introduction
  2. ~~~~~~~~~~~~~~~
  3.  
  4. Poly Tracker is a Scream Tracker 3 like tracker written by Lone Ranger of AcmE
  5. a thoroughly tested by ViC / AcmE and The REW / Nostalgia. The original
  6. intent was to release the tracker as a shareware product, but after the release
  7. of Fast Tracker 2, Lone Ranger decided the tracker would need a major face-lift
  8. before a 'commercial' release. ViC and The REW compose all of their music in
  9. Poly Tracker, and because they are rather succesful in doing so (they are the
  10. two best musicians in the Netherlands) more and more people ask for the format
  11. of the PTM (Poly Tracker Module) files Poly Tracker produces.
  12.  
  13. As is normal with coders, Lone Ranger did not have the PTM file format (like
  14. Otto Chrons of DMP still does not have a description of the AMF format), but
  15. because the Nostalgia products use PTM files I got some source code and header
  16. descriptions and stuff from Lone Ranger so I could draw up a simple format
  17. description. This description did not really suffice for a scene release
  18. (although a number of people already have this document), so here I am typing a
  19. less concise description allowing other scene members to support the PTM format
  20. in their players.
  21.  
  22. This is a description of version 2.03 of the PTM format. Early formats are no
  23. longer used or supported by the current version of Poly Tracker (it still says
  24. "version 1.0ß", but I think there have been about a dozen different versions,
  25. including some customized test versions), and therefor I stick to version 2.03
  26. here.
  27.  
  28. When writing Poly Tracker, Lone Ranger needed a simple, straight forward module
  29. format. Since Poly Tracker was to become a better Scream Tracker (both ViC and
  30. The REW liked the Scream Tracker 3 interface but the program itself did not
  31. meet their requirements) Lone Ranger took a quick look at the S3M format and
  32. decided to adept it to the needs of Poly Tracker. This means that the PTM
  33. format has many similiarities with the S3M format, leaving out some typical ST3
  34. fields and putting in some extra Poly Tracker specific stuff. This may cause
  35. the format to look a little awkard, but remember that it was never the
  36. intention to release a Poly Tracker using this specification - it was merely a
  37. convenient beta-version format.
  38.  
  39. This document is divided into several parts. First, I give a concise
  40. description of the PTM lay-out, followed by a more thorough and detailed
  41. explanation. The next section covers the effects used by Poly Tracker, followed
  42. by the last chapter, written for those who already include S3M support into
  43. their player, comparing the two formats.
  44.  
  45. Well, that's enough introduction chat, I hope you find this a useful document.
  46. Any questions regarding this format can be sent to me by e-mail. Until the end
  47. of August my address is kpvhekhu@cs.ruu.nl (I do not know what it will be from
  48. September, but it will be listed on the Nostalgia home page:
  49. http://pitel_lnx.ibk.hvu.nl/~therew/Nostalgia.html, where any updates of this
  50. document can also be found).
  51.  
  52.  
  53. JAL / Nostalgia, 27 May 1995
  54.  
  55.  
  56. 2) Concise description of the PTM format / PTM format reference
  57. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  58.  
  59. This is a concise description of the PTM format. Four columns are used: offset,
  60. name, type and description. (rel.)offset is the (relative) offset of the field,
  61. name is the field's name, type the field's type and description a short
  62. description (a more detailed description can be found in the next section). The
  63. field type descriptions used are:
  64.  
  65.   a = ascii character (8 bits)
  66.   b = byte (8 bits)
  67.   w = word (16 bits)
  68.   l = long (32 bits)
  69.  
  70. A number after the type indicates an array of that size (in elements). 'l4'
  71. would mean an array of 4 longs. All 'reserved' fields are currently not in use,
  72. neither internally nor externally.
  73.  
  74. I: header
  75.  
  76. offset      name         type description
  77.  
  78.   0         SongName     a28  name of song, asciiz string
  79.  28         EofMark      a    eof mark, #26
  80.  29         FileVersion  w    version of file, currently 0203h
  81.  31         Reserved1    b    reserved, set to 0
  82.  32         nOrders      w    number of orders (0..256)
  83.  34         nInstr       w    number of instruments (1..255)
  84.  36         nPatterns    w    number of patterns (1..128)
  85.  38         nChannels    w    number of channels (voices) used (1..32)
  86.  40         FileFlags    w    set to 0
  87.  42         Reserved2    w    reserved, set to 0
  88.  44         SongID       a4/l song identification, 'PTMF' or 464d5450h
  89.  48         Reserved3    b16  reserved, set to 0
  90.  64         ChSet        b32  channel panning settings, 0..15, 0 = left,
  91.                               7 = middle, 15 = right
  92.  96         Orders       b256 order list, valid entries 0..nOrders-1
  93. 352         PatSeg       w128 pattern segments (segment = 16 bytes)
  94. 608         (size)
  95.  
  96. II: instruments
  97.  
  98. The instrument data directly follows the header. It is an array of 0..nInstr-1
  99. of the following structure:
  100.  
  101. rel.offset  name         type description
  102.  
  103.   0         SampleType   b    sample type (bit array)
  104.   1         DOSName      a12  name of external sample file
  105.  13         Volume       b    default volume
  106.  14         C4Spd        w    C4 speed
  107.  16         SampleSeg    w    sample segment (*)
  108.  18         FileOfs      l    offset of sample data
  109.  22         Length       l    sample size (in bytes)
  110.  26         LoopBeg      l    start of loop
  111.  30         LoopEnd      l    end of loop
  112.  34         GUSBegin     l    GUS begin address (*)
  113.  38         GUSLStart    l    GUS loop start address (*)
  114.  42         GUSLEnd      l    GUS loop end address (*)
  115.  46         GUSLoop      b    GUS loop flags (*)
  116.  47         Reserved     b    reserved, set to 0
  117.  48         SampleName   a28  name of sample, asciiz
  118.  76         SampleID     a4/l sample identification, 'PTMS' or 534d5450h
  119.  80         (size)
  120.  
  121. SampleType bit flags:
  122.  
  123.   bits 0 and 1: 0 = no sample (instrument info only)
  124.                 1 = normal sample (FileOfs / Length fields are valid)
  125.                 2 = OPL2 / OPL3 instrument (not used)
  126.                 3 = MIDI instrument (not used)
  127.   bit 2: sample loop (0 = no loop, 1 = loop)
  128.   bit 3: loop type (0 = unidirectional, 1 = bidirectional)
  129.   bit 4: sample resolution (0 = 8 bits, 1 = 16 bits)
  130.  
  131. (*) these are used internally only, and set to 0 in the file
  132.  
  133. III: patterns
  134.  
  135. The patterns are stored after the instrument information. Each pattern starts
  136. at a 16-byte aligned position. The size of each pattern is calculated by
  137. subtracting the next offset from the current. The next offset for the last
  138. pattern is the offset of the first sample (retrieved from the first intrument's
  139. FileOfs field). This is a little akward and was due for improvement, but Lone
  140. Ranger never came around to doing it.
  141.  
  142. Data byte reference:
  143.  
  144. 0 - next row
  145. else: venc.cccc
  146.   ccccc - channel (0..31)
  147.   n - read note (1 byte, 254 (note off), 1..120 (c-0..b-9)) and sample number
  148.       (1 byte, 1..255)
  149.   e - read effect (1 byte, 0..22 (0..M)) and parameter(s) (1 byte (2 nibbles))
  150.   v - read volume (1 byte, 0..64)
  151.  
  152. IV: samples
  153.  
  154. The sample data follows the pattern data. Each sample starts at the offset as
  155. described in the FileOfs field of the instrument structure and has a length as
  156. described in the Length field.
  157.  
  158.  
  159. 3) Detailed description of the PTM format
  160. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  161.  
  162. I: header
  163.  
  164. The first 28 bytes are an asciiz string containing the name of the song,
  165. followed by a end-of-file mark, thus making the file typable. Next comes the
  166. file version (currently 2.03). All older versions are not compatible with the
  167. current format and players / trackers should not attempt to load them. After a
  168. reserved byte follow the number of entries in the order list (0..256), the
  169. number of instruments (1..255), the number of patterns (1..128), and the number
  170. of channels (voices) used (1..32).
  171.  
  172. To detect whether the file is a Poly Tracker module, check the longint at
  173. offset 44. The 4 characters here should contain the value 'PTMF'. ChSet
  174. contains the panning settings for the channels (0..15, 0 = left, 7 = middle, 15
  175. = right), Orders is the order list containing the pattern numbers to play.
  176.  
  177. PatSeg needs some further explanation. Poly Tracker loads a PTM file at offset
  178. 0 of the file's memory segment. All patterns are also paragraph aligned (i.e.
  179. at 16 byte (segment) bounderies), both in the memory as in the file (making it
  180. possible to load the header and the patterns in one read). The PatSeg array
  181. contains the absolute file offsets divided by 16. Thus, the first pattern has
  182. file offset PatSeg[0] * 16, the second PatSet[1] * 16 and so on. When
  183. PolyTracker loads the file, the PatSeg array is adjusted to contain the
  184. absolute segment numbers, by adding the file's segment to all PatSeg array
  185. elements. (Poly Tracker has some more tricks for internal pattern storage as it
  186. is capable of using EMS, but that's of no concern for this document.)
  187.  
  188. II: instruments
  189.  
  190. The instrument structure starts with a byte denoting the sample type. It is a
  191. bitarray, individual bits are used to store information. The first two bits
  192. either contain 0 (unused) or 1 (used). Other values are currently not in use.
  193. If a sample is unused the FileOfs and Length fields should be ignored (there is
  194. no sample data for this instrument in the file). Bit 2 indicates whether or not
  195. the sample should loop. 0 means no loop, 1 means looping is enabled. Bit 3 is
  196. only valid if bit 2 is set to 1. If bit 3 is set to 1, the sample loop should
  197. be played bi-directional, otherwise it is uni-directional. Bit 4 is the last
  198. bit defined. If set to 1, the sample is a 16 bit sample, 8 bit otherwise.
  199.  
  200. Following the sample type is the DOS file name of the original sample (since
  201. Poly Tracker cannot sample or create samples, all samples are loaded from
  202. disk). It has the usual format: filename, dot, extension. If the name conatians
  203. less than 12 characters it should be zero-extended.
  204.  
  205. Volume is the sample's default volume, and has a value from 0 up to 64. Note
  206. that, as with most trackers, this is not a relative, but an absolute value.
  207. Thus, it should be regarded as a first 'volume set' command. The C4Spd is the
  208. frequency of the sample when a C-4 is played. In older MOD formats this is also
  209. called C2 speed.
  210.  
  211. SampleSeg is the internal memory segment of the sample data and currently not
  212. used by Poly Tracker. FileOfs is the absolute offset of the sample data in the
  213. PTM file, length the size of the sample in bytes. LoopBeg and LoopEnd are the
  214. looping values (used only when SampleType bit 2 is set). When bit 4 of the
  215. sample type field is set (the sample is 16 bit), LoopBeg and LoopEnd should
  216. have an even value.
  217.  
  218. Since Poly Tracker loads the instruments directly into memory, there are some
  219. fields used only internally. The four GUS fields are used for internal
  220. management of the GUS heap and other GUS related variables, and should be set
  221. to 0 when on disk.
  222.  
  223. SampleName is an asciiz string containing the sample/instrument name (or some
  224. comment if the first two bits of sample type are set to 0). SampleID is the
  225. sample identification, containing the four characters 'PTMS'.
  226.  
  227. III: patterns
  228.  
  229. Patterns are stored row by row, each row containing none, one, or multiple
  230. voices. The patterns contain compressed information, as opposed to the
  231. one-position-one-byte approach of most trackers. In essence, patterns are a
  232. byte stream. The compression scheme is similar to the ST3 approach. Patterns
  233. always contain 64 rows. The decoding scheme is as follows:
  234.  
  235. repeat
  236.   read byte
  237.   if (byte = 0) then
  238.     next row
  239.   else
  240.     channel = bits 0..4
  241.     if (bit 5 is set) then
  242.       read note (1 byte)
  243.       read sample number (1 byte)
  244.     endif
  245.  
  246.     if (bit 6 is set) then
  247.       read effect (1 byte)
  248.       read effect parameter (1 byte)
  249.     endif
  250.  
  251.     if (bit 7 is set) then
  252.       read volume (1 byte)
  253.     endif
  254.   endif
  255. until 64 rows read
  256.  
  257. If the data byte is 0 it means that the current row contains no (more)
  258. information. If not, bit 5 is checked to see whether a note and sample
  259. information are stored. If so, they are read. Next, bit 6 is checked to see
  260. whether an effect and its parameter are stored. If so, they are read. Finally,
  261. bit 7 is checked. If bit 7 is set, this means that a volume byte is stored, and
  262. it is read. The patterns has been completely read when all 64 rows have been
  263. read (the current file format does not allow for any other number of rows).
  264.  
  265. The channel number is a number from 0 to 31 (or nChannels - 1 if less than 32
  266. channels are used). Note values are 254 (note off) or between 1 and 120: 1 =
  267. C-0, 120 = B-9. Sample number is a value between 1 and 255 (or nInstr if less
  268. than 255 instruments). The effect byte can have a value between 0 and 22. 0
  269. through 9 are effects 0 through 9, 10 through 22 are effects A through M (see
  270. next chapter for a description of the effects used). The last value, volume,
  271. can have a value between 0 and 64.
  272.  
  273. IV: samples
  274.  
  275. The samples are stored in a signed delta format, allowing a high compression
  276. rate with 8 bit samples. 16 bit samples are also stored this way, although they
  277. do not have the 8 bit compression advantage.
  278.  
  279. The following piece of C code shows how to convert the signed delta format to
  280. straight format:
  281.  
  282.   n = 0;
  283.   for (i = 0; i < size; i++)
  284.   {
  285.     n = (data[i] += n);
  286.     data[i] ^= 0x80;      // only when converting to unsigned
  287.   }
  288.  
  289. In Pascal:
  290.  
  291.   N := 0;
  292.   for I := 0 to Size-1 do begin
  293.     Data^[I] := Data^[I] + N;
  294.     N := Data^[I];
  295.     Data^[I] := Data^[I] xor $80;   {only when converting to unsigned}
  296.   end;
  297.  
  298. The current version does not allow for compressed samples, but when ZIPped or
  299. ARJed 8 bit delta samples compress considerably better than normally stored
  300. samples.
  301.  
  302.  
  303. 4) Poly Tracker Effects
  304. ~~~~~~~~~~~~~~~~~~~~~~~
  305.  
  306. Poly Tracer uses 23 effects, numbered 0 through 9 and A through M. Since I am
  307. no musician I do not know the precise meaning of the commands, but I trust most
  308. people *do* know, so I excluded a description of the commands.
  309.  
  310. cmd#    meaning
  311.  
  312. 0xy     arpeggio
  313. 1xx     slide down
  314. 1fx     fine slide down
  315. 1ex     extra fine slide down
  316. 2xx     slide up
  317. 2fx     fine slide up
  318. 2ex     extra fine slide up
  319. 3xx     tone portamento
  320. 4xy     vibrato (x = speed, y = depth)
  321. 5xy     tone portamento + volume slide
  322. 6xy     vibrato + volume slide
  323. 7xy     tremolo (x = speed, y = depth)
  324. 8xx     - (not used)
  325. 9xx     set sample offset (to xx00h)
  326. ax0     volume slide up
  327. a0x     volume slide down
  328. axf     fine volume slide up
  329. afx     fine volume slide down
  330. bxx     set song position
  331. cxx     set volume (for MTM/MOD compatibility only)
  332. dxx     set break position
  333. e0x     - (not used)
  334. e1x     fine slide down (for MTM/MOD compatibility only, use 1fx)
  335. e2x     fine slide up (for MTM/MOD compatibility only, use 2fx)
  336. e3x     - (not used)
  337. e4x     set vibrato wave form (see table 4.1)
  338. e5x     set sample fine tune value (see table 4.3)
  339. e60     set loop start
  340. e6x     loop to start
  341. e7x     set tremolo wave form (see table 4.1)
  342. e8x     set pan position (0 = left, 7 = middle, 15 = right)
  343. e9x     retrigger note (for MTM/MOD compatibility only, use h0x or h8x)
  344. eax     fine volume slide up (for MTM/MOD compatibility only, use axf)
  345. ebx     fine volume slide down (for MTM/MOD compatibility only, use afx)
  346. ecx     note cut (x = count)
  347. edx     note delay (x = count)
  348. eex     pattern delay (x = number of rows)
  349. efx     - (not used)
  350. dxx     break to next pattern (xx = position in next pattern)
  351. fxx     set speed (xx < 20h) or tempo (xx >= 20h)
  352. gxx     set global volume
  353. hxy     retrigger note + volume changes (x = volume (see table 4.2), y = count)
  354. ixy     fine vibrato (x = speed, y = depth)
  355. jxy     note slide down (x = speed, y = note count)
  356. kxy     note slide up (x = speed, y = note count)
  357. lxy     note slide down + note retrigger (x = speed, y = note count)
  358. mxy     note slide up + note retrigger (x = speed, y = note count)
  359.  
  360. table 4.1 - vibrato and tremolo wave forms
  361.   0: sine wave
  362.   1: ramp down
  363.   2: square wave
  364.   3: random
  365.  
  366. table 4.2 - retrigger note volume changes
  367.   0: no changes
  368.   1: volume - 1
  369.   2: volume - 2
  370.   3: volume - 4
  371.   4: volume - 8
  372.   5: volume - 16
  373.   6: volume * 2/3
  374.   7: volume * 1/2
  375.   8: no changes
  376.   9: volume + 1
  377.   a: volume + 2
  378.   b: volume + 4
  379.   c: volume + 8
  380.   d: volume + 16
  381.   e: volume * 3/2
  382.   f: volume * 2
  383.  
  384. table 4.3 - fine tune values to C4 speed values
  385.   0: 7895 Hz
  386.   1: 7941 Hz
  387.   2: 7985 Hz
  388.   3: 8046 Hz
  389.   4: 8107 Hz
  390.   5: 8169 Hz
  391.   6: 8232 Hz
  392.   7: 8280 Hz
  393.   8: 8363 Hz (no fine tune)
  394.   9: 8413 Hz
  395.   a: 8463 Hz
  396.   b: 8529 Hz
  397.   c: 8581 Hz
  398.   d: 8651 Hz
  399.   e: 8723 Hz
  400.   f: 8757 Hz  
  401.  
  402.  
  403. 5) Comparison of S3M and PTM Formats
  404. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  405.  
  406. The S3M format was chosen as a start for the PTM format because of the
  407. similarities between Poly Tracker and Scream Tracker. The current version of
  408. the PTM format (2.03) was never ment to be released, but as time caught up with
  409. the planned improvements, and more and more people asked for the PTM format,
  410. Lone Ranger decided to release it anyway. This section is a brief coverage of
  411. the differences between the two formats, intended as a quick guide for
  412. programmers who already have a S3M loader and want to write a PTM loader as
  413. well. The information is very concise, as it is taken directly from some info I
  414. wrote when writing a PTM to S3M converter.
  415.  
  416. I: header
  417.  
  418. PTM:                         S3M:
  419.   0 SongName      a28           0 SongName      a28
  420.  28 EofMark       a            28 EofMark       a
  421.  29 FileVersion   w            29 FileType      b
  422.  31 Reserved1     b            30 Reserved1     w
  423.  32 nOrders       w            32 nOrders       w
  424.  34 nInstr        w            34 nInstr        w
  425.  36 nPatterns     w            36 nPatterns     w
  426.  38 nChannels     w            38 Flags         w
  427.  40 FileFlags     w            40 TrackVer      w
  428.  42 Reserved2     w            42 FileVer       w
  429.  44 SongID        a4/l         44 FileID        a4/l
  430.  48 Reserved3     b16          48 GlobalVol     b
  431.                                49 InitSpeed     b
  432.                                50 InitTempo     b
  433.                                51 MasterVol     b
  434.                                52 Reserved2     b10
  435.                                62 SpecialPtr    w
  436.  64 ChSet         b32          64 ChanSet       b32
  437.  96 Orders        b256         96 Orders        b(nOrders)
  438. 352 PatSeg        w128        xxx InsPtr        w(nInstr)
  439. 608 (size)                    xxx PatternPtr    w(nPatterns)
  440.  
  441. II: instruments
  442.  
  443. PTM:                         S3M:
  444.   0 SampleType    b             0 SampleType    b
  445.   1 DOSName       a12           1 DosName       a12
  446.  13 Volume        b            13 MemSeg        b3/w
  447.  14 C2Spd         w            16 Length        l
  448.  16 SampleSeg     w            20 LoopBegin     l
  449.  18 FileOfs       l            24 LoopEnd       l
  450.  22 Length        l            28 Volume        b
  451.  26 LoopBeg       l            29 Reserved1     b
  452.  30 LoopEnd       l            30 Packing       b
  453.  34 GUSBegin      l            31 Flags         b
  454.  38 GUSLStart     l            32 C2Spd         l
  455.  42 GUSLEnd       l            36 Reserved2     l
  456.  46 GUSLoop       b            40 Internal1     w
  457.  47 Reserved      b            42 Internal2     w
  458.                                44 Internal3     l
  459.  48 SampleName    a28          48 SampleName    a28
  460.  76 SampleID      a4           76 SampleID      a4/l
  461.  80 (size)                     80 (size)
  462.  
  463. PTM sample type:
  464.  
  465.   bit 0, 1 (0 = no sample, 1 = sample, 2 = adlib, 3 = midi)
  466.       2 (0 = no loop, 1 = loop)
  467.       3 (0 = uni, 1 = bi)
  468.       4 (0 = 8, 1 = 16)
  469.  
  470. S3M sample type:
  471.  
  472.   0 = sample not used
  473.   1 = sample
  474.   2 = adlib melody
  475.   3+ = adlib drum
  476.  
  477. S3M sample flags:
  478.  
  479.   bit 0 = loop on
  480.       1 = stereo          (not supported!)
  481.       2 = 16-bit sample   (not supported!)
  482.  
  483. Storage format:
  484.  
  485. PTM stores samples in a signed delta format (start = 0), S3M in unsigned raw.
  486.  
  487. III: patterns
  488.  
  489. Both packed scheme: 0 = end of row, always 64 rows, else low nibble = channel,
  490. high-nibble = flags
  491.  
  492. bit: 567
  493. PTM: nev
  494. S3M: nve
  495.  
  496. n: after this byte follows note and instrument (1+1 bytes)
  497. e: after this byte follows effect and parameter (1+1 bytes)
  498. v: after this byte follows volume (1 byte)
  499.  
  500. If the bit is set the bytes follow, in order of bits.
  501.  
  502. 4) notes
  503.  
  504. PTM: 0 = empty, 1 = C-0, 2 = C#0, 3 = D-0, etc.  (12 steps within octave)
  505. S3M: hi = octave, lo = note, 255 = empty         (12+4 steps within octave)
  506.  
  507. both: 254 = ^^^ = key off
  508.  
  509. 5) commands
  510.  
  511. Note: PTM commands start with 0 up to 9, a = 10 etc., S3M commands start
  512.       with a = 0, b = 1 etc.
  513.  
  514. command        PTM          S3M
  515.  
  516. arpeggio      0           j
  517. slide down    1           e
  518. fine sd       1f          ef
  519. extra fsd     1e          ee
  520. slide up      2           f
  521. fine su       2f          ff
  522. extra fsu     2e          fe
  523. tone porta    3           g
  524. vibrato       4           h
  525. tp+vol sl     5           l
  526. vib+vol sl    6           k
  527. tremolo       7           r
  528. samp ofs      9           o
  529. vol sl up     a.0         d.0
  530. vol sl down   a0.         d0.
  531. fine vsd      af.         df.
  532. fine vsu      a.f         d.f
  533. songpos       b           b
  534. volume        c           -
  535. breakpos      d           c
  536. speed         f (<20h)    a
  537. tempo         f (>=20h)   t
  538. global vol    g           v
  539. retrig        h           q
  540. fine vib      i           u
  541. note sl down  j           -
  542. note sl up    k           -
  543. note sld+retr l           -
  544. note slu+retr m           -
  545.  
  546. fine sd       e1 (= 1f)   ef
  547. fine su       e2 (= 2f)   ff
  548. vib wave      e4          s3
  549. fine tune     e5          s2
  550. loop          e6          sb
  551. trem wave     e7          s4
  552. set pan pos   e8          s8
  553. retrig        e9 (= h8)   q8
  554. fine vsu      ea (= a.f)  d.f
  555. fine vsd      eb (= af.)  df.
  556. note cut      ec          sc
  557. note delay    ed          sd
  558. patt delay    ee          se
  559.  
  560.  
  561. 6) Closing Words
  562. ~~~~~~~~~~~~~~~~
  563.  
  564. Well, that's over 500 lines of information, I don't think any format has ever
  565. been covered so thoroughly. I hope I didn't forget any crucial information, if
  566. you need anymore info just write me (see introduction for my e-mail address).
  567.  
  568.  
  569. JAL / Nostalgia, 28 May 1995
  570.  
  571.